Sergiu Dumitriu wrote:

Marius Dumitru Florea wrote:

...

Hi there,

Here's the roadmap I propose:

* Fix current issues

** Write Selenium tests for all current features (JV). ** Provide a Range/Selection implementation for IE. (fixes XWIKI-2737, XWIKI-2738, XWIKI-2739). One option is to wrap this JavaScript code http://jorgenhorstink.nl/2006/07/05/dom-range-implementation-in-ecmascript-c... . I have Jorgen's permision to use his code. This will save me from implemeting it by myself (which is the second option). The third option is to use the selection support from rocket-gwt library ( http://code.google.com/p/rocket-gwt/wiki/Selections ), which is limited right now. I'm waiting for an answer regarding their roadmap. 24 man-hours ** Reimplement list support. (fixes XWIKI-2734). The default implementation doesn't wrap nested lits in a list item element and fails to detect the presence of a list when the cursor is on a list item with a nested list inside (generated by the wiki editor). Indent/outdent for nested lists have to be reimplemented also. 16 man-hours ** Improve history mechanism (fixes XWIKI-2731). I should restore the previous selection on Undo/Redo. Right now, only the cursor position is restored. 8 man-hours ** Reimplement the heading (using id's and possibly named anchors) and improve the Format plugin (by adding Inline and Paragraph options besides Title X). 8 man-hours ** Fix horizontal rule generation. (fixes XWIKI-2729) 2 man-hours ** Fix Insert Symbol features so it won't require any special encoding. (fixes XWIKI-2669) Right now I have no idea on how fix this. 6 man-hours ** Use the same styling in edit mode as in view mode. (fixes XWIKI-2721). I have to check what CSS rules from the Toucan style sheet messes up the editor. 8 man-hours ** Fix cursor issues (navigation through empty DOM nodes using arrow keys; avoid cursor hiding when the user clicks on an empty DOM element). 8 man-hours

----- Total: 80 man-hours // 1.7M1

* Integrate (& revisit) implemented features

** Justify (left, center, right, full) 3 man-hours ** Font (family, size) 3 man-hours ** Color (background, foreground) 3 man-hours

* Implement new features

** Teletype text. I have to discuss this with Vincent because there are two use cases. 16 man-hours. ** Definition lists. Currently there's no support at all. 22 man-hours ** Clear inline formatting. 2 man-hours ** Insert/Edit/Remove Link. I have to extend the built-in command "createlink" for our custom wiki link. We have to implement one big tabbed-dialog for insertion and the link inspector. We also need to implement the remote services for retrieving wiki, space, page, attachment names, as well as comments and history. 8+32 man-hours ** Insert/Edit Image. We have to implement the insert dialog and the image inspector. We also need to implement the remote services for uploading and retrieving images as/from attachments. 24 man-hours ** Insert/Edit Table. We have to implement the insert dialog and the table inspector. 24 man-hours ** Insert/Edit Macro. We have to implement the insert dialog and the macro inspector. 24 man-hours

----- Total: 161 man-hours // 1.7RC1

* Pending features (in case we finish all the above)

** Full screen editing. I have to investigate this more, so I'm not sure about the effort. 24 man-hours ** Paste/Import Office document fragments. Requires catching the paste event and some on-server clean-up. We may also need an insert dialog. 16 man-hours, provided the server part is already done. ** Find & Replace. 24 man-hours

----- Total: 64 man-hours

As you can see there are plenty of things to do. We have to finish them before Javapolis.

Pretty ambitious time estimates... Looks to me you don't expect many problems on the way, I'd rather double some of those values. Anyway, this looks good, good luck!

We'll see how things evolve. Once the foundation (cross-browser implementation for Range and Selection) is in place then we shouldn't face big problems. Anyway this time, thanks to JV, we'll have automated functional tests so we'll be much more confident in the result.

And Happy Birthday, Marius!

Thanks a lot Sergiu!

Hi Vincent, Unfortunately I managed to do only the second point so far. I'll commit today the W3C Range and Selection implementation for IE. It took longer because: * In the end I had to do my own implementation because: ** I haven't received an answer to my question on GWT Google Groups (see http://tinyurl.com/67v4do ). ** The selection support from rocket-gwt library is very limited right now which makes it unusable for WYSIWYG editing (see http://tinyurl.com/5pvul5 ). ** Jorgen's Range implementation is generic, independent of any browser, relying only on DOM API, but in order to use it you need to be able to make the browser aware of that range and for this you need of course browser dependent code. I think that using such a generic implementation and writing the code to apply it to IE will result in a slower editor than using an implementation for Range that relies directly on IE's API, which I did in the end. * I spent some time with my evaluation and Ludovic's trainings. Thus I propose we postpone 1.7M1 with 3 days (23rd of October, in the morning) so that I can finish the rest of the points for this release. Marcela is working on the UI and underlying services (Insert Link dialog mainly and needed services) and as soon as I finish the points for 1.7M1 I'll review and integrate her code. Thanks, Marius Vincent Massol wrote:

Hi Marius,

On Oct 7, 2008, at 12:30 AM, Marius Dumitru Florea wrote:

...

Hi there,

Here's the roadmap I propose:

* Fix current issues

** Write Selenium tests for all current features (JV). ** Provide a Range/Selection implementation for IE. (fixes XWIKI-2737, XWIKI-2738, XWIKI-2739). One option is to wrap this JavaScript code http://jorgenhorstink.nl/2006/07/05/dom-range-implementation-in-ecmascript-c... . I have Jorgen's permision to use his code. This will save me from implemeting it by myself (which is the second option). The third option is to use the selection support from rocket-gwt library ( http://code.google.com/p/rocket-gwt/wiki/Selections ), which is limited right now. I'm waiting for an answer regarding their roadmap. 24 man- hours ** Reimplement list support. (fixes XWIKI-2734). The default implementation doesn't wrap nested lits in a list item element and fails to detect the presence of a list when the cursor is on a list item with a nested list inside (generated by the wiki editor). Indent/outdent for nested lists have to be reimplemented also. 16 man-hours ** Improve history mechanism (fixes XWIKI-2731). I should restore the previous selection on Undo/Redo. Right now, only the cursor position is restored. 8 man-hours ** Reimplement the heading (using id's and possibly named anchors) and improve the Format plugin (by adding Inline and Paragraph options besides Title X). 8 man-hours ** Fix horizontal rule generation. (fixes XWIKI-2729) 2 man-hours ** Fix Insert Symbol features so it won't require any special encoding. (fixes XWIKI-2669) Right now I have no idea on how fix this. 6 man- hours ** Use the same styling in edit mode as in view mode. (fixes XWIKI-2721). I have to check what CSS rules from the Toucan style sheet messes up the editor. 8 man-hours ** Fix cursor issues (navigation through empty DOM nodes using arrow keys; avoid cursor hiding when the user clicks on an empty DOM element). 8 man-hours

Since we're getting very close to the 1.7M1 release (on Monday), could you please let us know the status for each item above?

This will also allows us to help you in re-testing them all.

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

Vincent Massol wrote:

On Oct 17, 2008, at 11:20 AM, Marius Dumitru Florea wrote:

...

Hi Vincent,

Unfortunately I managed to do only the second point so far. I'll commit today the W3C Range and Selection implementation for IE. It took longer because:

* In the end I had to do my own implementation because:

** I haven't received an answer to my question on GWT Google Groups (see http://tinyurl.com/67v4do ).

Maybe you could ping them kindly again?

Done.

...

** The selection support from rocket-gwt library is very limited right now which makes it unusable for WYSIWYG editing (see http://tinyurl.com/5pvul5 ). ** Jorgen's Range implementation is generic, independent of any browser, relying only on DOM API, but in order to use it you need to be able to make the browser aware of that range and for this you need of course browser dependent code. I think that using such a generic implementation and writing the code to apply it to IE will result in a slower editor than using an implementation for Range that relies directly on IE's API, which I did in the end.

* I spent some time with my evaluation and Ludovic's trainings.

Thus I propose we postpone 1.7M1 with 3 days (23rd of October, in the morning) so that I can finish the rest of the points for this release.

I don't think we should do that. There's no warranty it's going to be only 3 days and it'll probably slip by more. I prefer that we keep our defined dates and release 1.7M1 as planned. It won't change anything for you since you can finish those for 1.7M2 if you don't succeed in finishing them for 1.7M1 (would be best of course).

ok, I'll see what I can do during the weekend.

Thanks -Vincent

...

Marcela is working on the UI and underlying services (Insert Link dialog mainly and needed services) and as soon as I finish the points for 1.7M1 I'll review and integrate her code.

Thanks, Marius

Vincent Massol wrote:

...

Hi Marius,

On Oct 7, 2008, at 12:30 AM, Marius Dumitru Florea wrote:

...

Hi there,

Here's the roadmap I propose:

* Fix current issues

** Write Selenium tests for all current features (JV). ** Provide a Range/Selection implementation for IE. (fixes XWIKI-2737, XWIKI-2738, XWIKI-2739). One option is to wrap this JavaScript code http://jorgenhorstink.nl/2006/07/05/dom-range-implementation-in-ecmascript-c... . I have Jorgen's permision to use his code. This will save me from implemeting it by myself (which is the second option). The third option is to use the selection support from rocket-gwt library ( http://code.google.com/p/rocket-gwt/wiki/Selections ), which is limited right now. I'm waiting for an answer regarding their roadmap. 24 man- hours ** Reimplement list support. (fixes XWIKI-2734). The default implementation doesn't wrap nested lits in a list item element and fails to detect the presence of a list when the cursor is on a list item with a nested list inside (generated by the wiki editor). Indent/outdent for nested lists have to be reimplemented also. 16 man-hours ** Improve history mechanism (fixes XWIKI-2731). I should restore the previous selection on Undo/Redo. Right now, only the cursor position is restored. 8 man-hours ** Reimplement the heading (using id's and possibly named anchors) and improve the Format plugin (by adding Inline and Paragraph options besides Title X). 8 man-hours ** Fix horizontal rule generation. (fixes XWIKI-2729) 2 man-hours ** Fix Insert Symbol features so it won't require any special encoding. (fixes XWIKI-2669) Right now I have no idea on how fix this. 6 man- hours ** Use the same styling in edit mode as in view mode. (fixes XWIKI-2721). I have to check what CSS rules from the Toucan style sheet messes up the editor. 8 man-hours ** Fix cursor issues (navigation through empty DOM nodes using arrow keys; avoid cursor hiding when the user clicks on an empty DOM element). 8 man-hours Since we're getting very close to the 1.7M1 release (on Monday), could you please let us know the status for each item above?

This will also allows us to help you in re-testing them all.

Thanks -Vincent

---

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

Hi guys, [lots of snapping below] *Marius*

...

...

Marcela is working on the UI and underlying services (Insert Link dialog mainly and needed services) and as soon as I finish the points for 1.7M1 I'll review and integrate her code.

I have pinged Laurent on the topic, he will deliver his UI mockups before the end of the week so that Marcela can keep her work going. *Marius*

...

...

...

...

Here's the roadmap I propose:

* Fix current issues

** Write Selenium tests for all current features (JV). ** Provide a Range/Selection implementation for IE. (fixes XWIKI-2737, XWIKI-2738, XWIKI-2739). One option is to wrap this JavaScript code

http://jorgenhorstink.nl/2006/07/05/dom-range-implementation-in-ecmascript-c...

...

. I have Jorgen's permision to use his code. This will save me from implemeting it by myself (which is the second option). The third option is to use the selection support from rocket-gwt library ( http://code.google.com/p/rocket-gwt/wiki/Selections ), which is limited right now. I'm waiting for an answer regarding their roadmap. 24 man-hours ** Reimplement list support. (fixes XWIKI-2734). The default implementation doesn't wrap nested lits in a list item element and fails to detect the presence of a list when the cursor is on a list item with a nested list inside (generated by the wiki editor). Indent/outdent for nested lists have to be reimplemented also. 16 man-hours ** Improve history mechanism (fixes XWIKI-2731). I should restore the previous selection on Undo/Redo. Right now, only the cursor position is restored. 8 man-hours ** Reimplement the heading (using id's and possibly named anchors) and improve the Format plugin (by adding Inline and Paragraph options besides Title X). 8 man-hours ** Fix horizontal rule generation. (fixes XWIKI-2729) 2 man-hours ** Fix Insert Symbol features so it won't require any special encoding. (fixes XWIKI-2669) Right now I have no idea on how fix this. 6 man- hours ** Use the same styling in edit mode as in view mode. (fixes XWIKI-2721). I have to check what CSS rules from the Toucan style sheet messes up the editor. 8 man-hours ** Fix cursor issues (navigation through empty DOM nodes using arrow keys; avoid cursor hiding when the user clicks on an empty DOM element). 8 man-hours

*Vincent*

...

...

Since we're getting very close to the 1.7M1 release (on Monday), could you please let us know the status for each item above?

This will also allows us to help you in re-testing them all.

*Marius*

...

...

Unfortunately I managed to do only the second point so far. I'll commit today the W3C Range and Selection implementation for IE. It took longer because in the end I had to do my own implementation.

Since work on the new editor is taking longer than expected, I made a prioritized list of the features that are crucial for XE 1.7 final. *Features we cannot ship the rich text editor without (those features have to work the same in IE6 / IE7 / FF2 / FF3):* 1. Hitting return creates a new paragraph 2. Clicking on the Bold / Italics / Underline / Strikethrough buttons applies the style to the current text selection 3. Clicking on H1 / H2 / H3 / H4 / H5 turns the current line into a header. Other style options are greyed. Clicking again turns the line of text back into normal text. 4. Clicking on a list button triggers the matching list behavior (either bulleted or numbered). Lists can be indented. 5. An user can turn a text selection into a wiki link. He can browse for the wiki page he wants to link to or search for it. 6. An user can turn a highlighted text selection into a link towards an external URL 7. An user can turn a highlighted text selection into a link towards a new wiki page *Features we'd better not ship the richt text editor without **(those features have to work the same in IE6 / IE7 / FF2 / FF3):* 1. Table insertion: the user can insert a standard wiki table and define how many rows / columns it should have. 2. Macro insertion: the user can select a macro from a list and click on insert to add that macro to the page 3. Macro rendering: the macro content is shown in -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

On Oct 21, 2008, at 3:54 PM, Guillaume Lerouge wrote:

*My reply was sent too fast once again today. Here's the full version.*

Hi guys,

...

[lots of snapping below]

*Marius*

...

...

...

Marcela is working on the UI and underlying services (Insert Link dialog mainly and needed services) and as soon as I finish the points for 1.7M1 I'll review and integrate her code.

*Guillaume*

...

I have pinged Laurent on the topic, he will deliver his UI mockups before the end of the week so that Marcela can keep her work going.

*Marius*

...

...

...

...

> Here's the roadmap I propose: > > * Fix current issues > > ** Write Selenium tests for all current features (JV). > ** Provide a Range/Selection implementation for IE. (fixes > XWIKI-2737, > XWIKI-2738, XWIKI-2739). One option is to wrap this JavaScript > code > http://jorgenhorstink.nl/2006/07/05/dom-range-implementation-in-ecmascript-c... > . I have Jorgen's permision to use his code. This will save me > from > implemeting it by myself (which is the second option). The third > option > is to use the selection support from rocket-gwt library ( > http://code.google.com/p/rocket-gwt/wiki/Selections ), which is > limited > right now. I'm waiting for an answer regarding their roadmap. 24 > man-hours > ** Reimplement list support. (fixes XWIKI-2734). The default > implementation doesn't wrap nested lits in a list item element > and > fails to detect the presence of a list when the cursor is on a > list item > with a nested list inside (generated by the wiki editor). Indent/outdent > for nested lists have to be reimplemented also. 16 man-hours > ** Improve history mechanism (fixes XWIKI-2731). I should > restore > the previous selection on Undo/Redo. Right now, only the cursor position > is restored. 8 man-hours > ** Reimplement the heading (using id's and possibly named > anchors) > and improve the Format plugin (by adding Inline and Paragraph > options > besides Title X). 8 man-hours > ** Fix horizontal rule generation. (fixes XWIKI-2729) 2 man- > hours > ** Fix Insert Symbol features so it won't require any special > encoding. (fixes XWIKI-2669) Right now I have no idea on how fix this. 6 man- > hours > ** Use the same styling in edit mode as in view mode. (fixes > XWIKI-2721). I have to check what CSS rules from the Toucan > style sheet > messes up the editor. 8 man-hours > ** Fix cursor issues (navigation through empty DOM nodes using > arrow > keys; avoid cursor hiding when the user clicks on an empty DOM > element). 8 man-hours

*Vincent*

...

...

...

Since we're getting very close to the 1.7M1 release (on Monday), could you please let us know the status for each item above?

This will also allows us to help you in re-testing them all.

*Marius*

...

...

...

Unfortunately I managed to do only the second point so far. I'll commit today the W3C Range and Selection implementation for IE. It took longer because in the end I had to do my own implementation.

*Guillaume*

...

Since work on the new editor is taking longer than expected, I made a prioritized list of the features that are crucial for XE 1.7 final. Marius & Marcela, please tell me if you need more details (aside from upcoming mockups).

*Features we cannot ship the rich text editor without (those features have to work the same in IE6 / IE7 / FF2 / FF3):*

1. Hitting return creates a new paragraph 2. Clicking on the Bold / Italics / Underline / Strikethrough buttons applies the style to the current text selection 3. Clicking on H1 / H2 / H3 / H4 / H5 turns the current line into a header. Other style options are greyed. Clicking again turns the line of text back into normal text. 4. Clicking on a list button triggers the matching list behavior (either bulleted or numbered). Lists can be indented. 5. The user can turn a text selection into a wiki link. He can browse for the wiki page he wants to link to or search for it. 6. The user can turn a highlighted text selection into a link towards an external URL 7. The user can turn a highlighted text selection into a link towards a new (currently not existing) wiki page 8. The user can select an image on his local computer and insert it into the wiki page 9. The user can select a file on his local computer and attach it to the wiki page 10. Table insertion: the user can insert a standard wiki table and define how many rows / columns it should have. 11. A table cell can include a list, an image or a header

This is too hard for 1.7. It requires adding some new features to the rendering. I think that's for 1.8. Thanks -Vincent

...

12. Macro insertion: the user can select a macro from a list and click on insert to add that macro to the page 13. Macro rendering: the macro content is shown with a rectangular line around it. When the cursor is put within that line, the macro background color changes. A "refresh" button is available for the users to refresh the macro's rendered content.

In this order of priority.

I'd like to highlight the fact that the single biggest complaint about the current editor is that, often, clicking on a button does not lead to the expected behaviour on the part of the application. Therefore, we need to make sure each feature behaves as expected under all 4 browsers before starting work on the next one. I know this sounds obvious - so let's make sure it becomes a reality ;-)

Thanks all for your hard work making the editor real !

Guillaume

Vincent Massol wrote:

On Oct 17, 2008, at 11:20 AM, Marius Dumitru Florea wrote:

...

Hi Vincent,

Unfortunately I managed to do only the second point so far. I'll commit today the W3C Range and Selection implementation for IE. It took longer because:

* In the end I had to do my own implementation because:

** I haven't received an answer to my question on GWT Google Groups (see http://tinyurl.com/67v4do ).

Maybe you could ping them kindly again?

...

** The selection support from rocket-gwt library is very limited right now which makes it unusable for WYSIWYG editing (see http://tinyurl.com/5pvul5 ). ** Jorgen's Range implementation is generic, independent of any browser, relying only on DOM API, but in order to use it you need to be able to make the browser aware of that range and for this you need of course browser dependent code. I think that using such a generic implementation and writing the code to apply it to IE will result in a slower editor than using an implementation for Range that relies directly on IE's API, which I did in the end.

* I spent some time with my evaluation and Ludovic's trainings.

Thus I propose we postpone 1.7M1 with 3 days (23rd of October, in the morning) so that I can finish the rest of the points for this release.

I don't think we should do that. There's no warranty it's going to be only 3 days and it'll probably slip by more. I prefer that we keep our defined dates and release 1.7M1 as planned. It won't change anything for you since you can finish those for 1.7M2 if you don't succeed in finishing them for 1.7M1 (would be best of course).

+1

...

Marcela is working on the UI and underlying services (Insert Link dialog mainly and needed services) and as soon as I finish the points for 1.7M1 I'll review and integrate her code.

Thanks, Marius

Vincent Massol wrote:

...

Hi Marius,

On Oct 7, 2008, at 12:30 AM, Marius Dumitru Florea wrote:

...

Hi there,

Here's the roadmap I propose:

* Fix current issues

** Write Selenium tests for all current features (JV). ** Provide a Range/Selection implementation for IE. (fixes XWIKI-2737, XWIKI-2738, XWIKI-2739). One option is to wrap this JavaScript code http://jorgenhorstink.nl/2006/07/05/dom-range-implementation-in-ecmascript-c... . I have Jorgen's permision to use his code. This will save me from implemeting it by myself (which is the second option). The third option is to use the selection support from rocket-gwt library ( http://code.google.com/p/rocket-gwt/wiki/Selections ), which is limited right now. I'm waiting for an answer regarding their roadmap. 24 man- hours ** Reimplement list support. (fixes XWIKI-2734). The default implementation doesn't wrap nested lits in a list item element and fails to detect the presence of a list when the cursor is on a list item with a nested list inside (generated by the wiki editor). Indent/outdent for nested lists have to be reimplemented also. 16 man-hours ** Improve history mechanism (fixes XWIKI-2731). I should restore the previous selection on Undo/Redo. Right now, only the cursor position is restored. 8 man-hours ** Reimplement the heading (using id's and possibly named anchors) and improve the Format plugin (by adding Inline and Paragraph options besides Title X). 8 man-hours ** Fix horizontal rule generation. (fixes XWIKI-2729) 2 man-hours ** Fix Insert Symbol features so it won't require any special encoding. (fixes XWIKI-2669) Right now I have no idea on how fix this. 6 man- hours ** Use the same styling in edit mode as in view mode. (fixes XWIKI-2721). I have to check what CSS rules from the Toucan style sheet messes up the editor. 8 man-hours ** Fix cursor issues (navigation through empty DOM nodes using arrow keys; avoid cursor hiding when the user clicks on an empty DOM element). 8 man-hours Since we're getting very close to the 1.7M1 release (on Monday), could you please let us know the status for each item above?

This will also allows us to help you in re-testing them all.

Thanks -Vincent

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Hi Paul, Paul Libbrecht wrote:

Marius,

are you anyways depending on rocket-gwt?

No. I was considering using it for its Selection support, but I discovered this support is limited for what I need.

Although we were enthusiastic about it for "skills-text-box", I am about to give it up. Rocket is mostly the work of one person and some of its features such as the stacktrace compilation warning kept byting my IDEA away from it, till impossibility of building.

Rocket is still in 0.x which has made it that the component we use was actually dropped between 0.4 and 0.5.2... something quite annoying...

So if you have the choice, just be warned.

Thanks for the tip.

paul

PS: isn't w3c range a super modern specification? I think saw trafic about it on the public-webapp w3c mailing-list recently. This would explain why it is not implemented everywhere.

Actually Mozilla follows pretty close the W3C Range specification http://developer.mozilla.org/en/DOM/range . Other important browsers are trying to do the same http://www.quirksmode.org/dom/range_intro.html . Internet Explorer, of course, doesn't care about specifications. Best regards, Marius

On 17-oct.-08, at 11:20, Marius Dumitru Florea wrote:

...

** The selection support from rocket-gwt library is very limited right now which makes it unusable for WYSIWYG editing (see http://tinyurl.com/5pvul5 ).

------------------------------------------------------------------------

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

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

Hi,

The last proposal for links management in the wysiwyg editor can be found here : http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys...

Sounds nice. Some comments: * The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me) * The screenshots are missing wiki selection (for multi wiki installs) * I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. * It's missing the ability to specify any number of parameters (for advanced usages) Thanks -Vincent

On Oct 28, 2008, at 4:45 PM, Marius Dumitru Florea wrote:

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

...

Hi,

The last proposal for links management in the wysiwyg editor can be found here : http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys...

Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me) * The screenshots are missing wiki selection (for multi wiki installs) * I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only.

I'm not into the wizard approach also. One reason is indeed the fact that I have to step through 3 dialogs or so in order to insert an internal link.

Yes

Another reason is that the solution with extended lists is not scalable at all. The Main space on xwiki.org has more than 100 pages (I discovered this after I killed next.dev.curriki by trying to view the space index for XWiki space..) so scrolling through these 100 pages is a pain. Why not using filterable combo boxes?

Yes I agree, I would have preferred the solution of using our filterable dynamic tables as proposed by guillaume on http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface The proposed design would be perfect for an iPhone I think but I think we have a bit more screen estate when on a standard computer. Thanks -Vincent

...

* It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent

Anca Paula Luca wrote:

Marius Dumitru Florea wrote:

...

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

...

Hi,

The last proposal for links management in the wysiwyg editor can be found here : http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys... Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me) * The screenshots are missing wiki selection (for multi wiki installs) * I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. I'm not into the wizard approach also. One reason is indeed the fact that I have to step through 3 dialogs or so in order to insert an internal link. Another reason is that the solution with extended lists is not scalable at all. The Main space on xwiki.org has more than 100 pages (I discovered this after I killed next.dev.curriki by trying to view the space index for XWiki space..) so scrolling through these 100 pages is a pain. Why not using filterable combo boxes?

Wizards seem indeed a little too much, at least the way I see things, that the link should be something quite fast to add. I was thinking about suggest boxes since *the user should know already something about where he wants to link*. He will very very very rarely need to see *all* pages / spaces to choose one (it's not like he's picking randomly!)

My extreme approach for this would be a suggest in which the user would write something like: <wikiName>:<SpaceName>.<PageName> and he would have suggestions for each of the 3 fields.

Now I am very aware that this might seem cryptic for a lot of users so just 3 suggest fields could do it. This can also help with: * not loading the whole list of spaces / pages, since we could load suggestions only after we got some hints from the user (the first letter, for example) * allowing the user to insert a page that does not exist in the same input as an existing page/space, thus transparently creating a link to a new page (I'm not really sure we want that, though)

Forgot to mention, suggest boxes is almost the same thing as the filterable combo boxes, in the end, something that would allow you to type and see the matches for what you type, but also show you the whole list if you really, really want to see it.

Happy coding, Anca Luca

...

...

* It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent

_______________________________________________ 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

Hi, On Tue, Oct 28, 2008 at 5:30 PM, Vincent Massol <[email protected]> wrote:

On Oct 28, 2008, at 5:22 PM, Anca Paula Luca wrote:

...

Anca Paula Luca wrote:

...

Marius Dumitru Florea wrote:

...

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

...

Hi,

The last proposal for links management in the wysiwyg editor can be found here :

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys... Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me)

This is not due to the label itself but to the very concept it's covering. Creating a link towards a page that does not exist yet, thus inviting users to create it at a later stage is a key wiki concept that has always been hard to explain to new wiki users. Whatever the name we choose, it will not be an optimal one. A way to improve this would be to add a little information button that triggers a tooltip explaining that creating a link towards a wanted page means creating a link towards a page that does not exist yet but that other users are encouraged to create.

...

...

...

...

* The screenshots are missing wiki selection (for multi wiki installs)

Wiki selection is planned (it would be a wiki selection page at the beginning of the wizard) and was not added because it does not change the logic of screenshots.

...

...

...

...

* I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. I'm not into the wizard approach also. One reason is indeed the fact that I have to step through 3 dialogs or so in order to insert an internal link. Another reason is that the solution with extended lists is not scalable at all. The Main space on xwiki.org has more than 100 pages (I discovered this after I killed next.dev.curriki by trying to view the space index for XWiki space..) so scrolling through these 100 pages is a pain. Why not using filterable combo boxes?

Wizards seem indeed a little too much, at least the way I see things, that the link should be something quite fast to add.

Yep me too

...

I was thinking about suggest boxes

...

since *the user should know already something about where he wants to link*. He will very very very rarely need to see *all* pages / spaces to choose one (it's not like he's picking randomly!)

My extreme approach for this would be a suggest in which the user would write something like: <wikiName>:<SpaceName>.<PageName> and he would have suggestions for each of the 3 fields.

I agree that's too cryptic and the several suggest boxes ideas is better.

...

...

Now I am very aware that this might seem cryptic for a lot of users so just 3 suggest fields could do it. This can also help with: * not loading the whole list of spaces / pages, since we could load suggestions only after we got some hints from the user (the first letter, for example) * allowing the user to insert a page that does not exist in the same input as an existing page/space, thus transparently creating a link to a new page (I'm not really sure we want that, though)((

Forgot to mention, suggest boxes is almost the same thing as the filterable combo boxes, in the end, something that would allow you to type and see the matches for what you type, but also show you the whole list if you really, really want to see it.

Yes I'm +1 for that (suggest fields + list below as it's done for the RMUI). Basically as it was proposed by Guillaume initially.

I disagree with this proposal. Even though I am its original writer, I now think that it is does not suit well the needs of the people we expect to use our WYSIWYG editor, for a number of reasons. 1. We do not need link insertion to be fast, we need it to be easy to understand for a wiki newbie. If the user is unable to understand how link creation works the very first time he's looking at the dialog box, without reading any kind of manual, he simply won't try doing it ever again. That would be a definite FAIL. 2. This proposal was written by a geek, with geeks in mind, assuming fantasy use cases. We spend more than 60% of our uptime in front of a computer screen and we are used to complex interfaces such as JIRA's or an IDE's. Therefore we are NOT representative of what 80% of our users will want to use. The interface I have suggested is too complex for a newcomer (too many columns, too many options, complex behaviors) 3. It does not matter if creating a link in the WYSIWYG editor takes some time. How many links do we expect our users to create in a typical day? I do not think that a typical user will create more than maybe 5 links a day. Since the beginning of the week, even though I am a heavy wiki user, I may not have created more than 2 links on our intranet. So if it takes 20 seconds to create one, it does not matter whatsoever. 4. We need to guide our users. People are used to their computers' folder hierarchy. I'm looking for the Word document that is in my personal files folders that is in my My Documents folder on my main hard drive. Power users use search. Most users browse. So providing simple browsing as the main option for creating links is probably the right thing to do. 5. People who truly care about speed will use the wiki editor anyway. It will ALWAYS be faster to write {{xhtml}} {{/xhtml}} than to click a button to trigger a dialog box, then click a macro to select it and so on. Power Users tend to use the wiki editor once they feel familiar with the wiki concept. 6. As for the technical issue - mainly scalability of we want to offer a list of 150 or so pages with a real scroll (not a JS one). I'm sure (ok, I strongly hope) that here are ways to optimize the underlying storage mecanism in order for it to have an index of all spaces and an index of all pages in every space available upon request. What's more, it is Laurent's job to have an insight into what our customers and users will expect. The same way I trust you guys for delivering a great architecture or clean, working and tested code, I trust Laurent for proposing an interface that actual users will want to use. I am NOT an UI engineer. Designing great UIs requires skills, experience and patience. It's all too easy for us to come and give our opinion about mockups. However if designing great interfaces was that easy our users wouldn't be saying that XWiki is hard to use :-) So even though I would personally benefit more from the complex UI I've proposed, I think the best thing we can do for XWiki right now is to think about real people who hardly know how to use a wiki and provide them with a dead-simple, wizard-based interface with very little options that will guide them through the whole process. Let's accept it: we're not the WYSIWYG editor's target market. Our mothers are. And my mother would be definitely unable to use the interface I've suggested :-) Guillaume

Thanks -Vincent

...

...

Happy coding, Anca Luca

...

...

* It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent

---

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

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

Hi Guillaume, Guillaume Lerouge wrote:

Hi,

On Tue, Oct 28, 2008 at 5:30 PM, Vincent Massol <[email protected]> wrote:

...

On Oct 28, 2008, at 5:22 PM, Anca Paula Luca wrote:

...

Anca Paula Luca wrote:

...

Marius Dumitru Florea wrote:

...

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

> Hi, > > The last proposal for links management in the wysiwyg editor can > be > found here : > http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys... Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me)

This is not due to the label itself but to the very concept it's covering. Creating a link towards a page that does not exist yet, thus inviting users to create it at a later stage is a key wiki concept that has always been hard to explain to new wiki users. Whatever the name we choose, it will not be an optimal one. A way to improve this would be to add a little information button that triggers a tooltip explaining that creating a link towards a wanted page means creating a link towards a page that does not exist yet but that other users are encouraged to create.

...

...

...

...

...

* The screenshots are missing wiki selection (for multi wiki installs)

Wiki selection is planned (it would be a wiki selection page at the beginning of the wizard) and was not added because it does not change the logic of screenshots.

...

...

...

...

...

* I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. I'm not into the wizard approach also. One reason is indeed the fact that I have to step through 3 dialogs or so in order to insert an internal link. Another reason is that the solution with extended lists is not scalable at all. The Main space on xwiki.org has more than 100 pages (I discovered this after I killed next.dev.curriki by trying to view the space index for XWiki space..) so scrolling through these 100 pages is a pain. Why not using filterable combo boxes? Wizards seem indeed a little too much, at least the way I see things, that the link should be something quite fast to add. Yep me too

...

I was thinking about suggest boxes

...

since *the user should know already something about where he wants to link*. He will very very very rarely need to see *all* pages / spaces to choose one (it's not like he's picking randomly!)

My extreme approach for this would be a suggest in which the user would write something like: <wikiName>:<SpaceName>.<PageName> and he would have suggestions for each of the 3 fields. I agree that's too cryptic and the several suggest boxes ideas is better.

...

...

Now I am very aware that this might seem cryptic for a lot of users so just 3 suggest fields could do it. This can also help with: * not loading the whole list of spaces / pages, since we could load suggestions only after we got some hints from the user (the first letter, for example) * allowing the user to insert a page that does not exist in the same input as an existing page/space, thus transparently creating a link to a new page (I'm not really sure we want that, though)(( Forgot to mention, suggest boxes is almost the same thing as the filterable combo boxes, in the end, something that would allow you to type and see the matches for what you type, but also show you the whole list if you really, really want to see it. Yes I'm +1 for that (suggest fields + list below as it's done for the RMUI). Basically as it was proposed by Guillaume initially.

I disagree with this proposal. Even though I am its original writer, I now think that it is does not suit well the needs of the people we expect to use our WYSIWYG editor, for a number of reasons.

1. We do not need link insertion to be fast, we need it to be easy to understand for a wiki newbie. If the user is unable to understand how link creation works the very first time he's looking at the dialog box, without reading any kind of manual, he simply won't try doing it ever again. That would be a definite FAIL.

I don't think the target is to make something that a wiki newbie would understand from the first time, but rather something with a fast learning curve for most of our wiki newbies. We should focus on the day to day usage, after the user has understood the concept of space and page. In this case I'm convinced he values a lot the speed. Browsers offer suggestions when you type in the address bar. This is not something new. Google Suggest uses the same mechanism. Thus I don't think a newbie user will find difficult the selection of a space with a filterable combo box (input suggest).

2. This proposal was written by a geek, with geeks in mind, assuming fantasy use cases. We spend more than 60% of our uptime in front of a computer screen and we are used to complex interfaces such as JIRA's or an IDE's. Therefore we are NOT representative of what 80% of our users will want to use. The interface I have suggested is too complex for a newcomer (too many columns, too many options, complex behaviors) 3. It does not matter if creating a link in the WYSIWYG editor takes some time. How many links do we expect our users to create in a typical day? I do not think that a typical user will create more than maybe 5 links a day. Since the beginning of the week, even though I am a heavy wiki user, I may not have created more than 2 links on our intranet. So if it takes 20 seconds to create one, it does not matter whatsoever.

I don't think user dissatisfaction resets after each day but grows till a the user finds a better solution elsewhere.

4. We need to guide our users. People are used to their computers' folder hierarchy. I'm looking for the Word document that is in my personal files folders that is in my My Documents folder on my main hard drive. Power users use search. Most users browse. So providing simple browsing as the main option for creating links is probably the right thing to do. 5. People who truly care about speed will use the wiki editor anyway. It will ALWAYS be faster to write {{xhtml}} {{/xhtml}} than to click a button to trigger a dialog box, then click a macro to select it and so on. Power Users tend to use the wiki editor once they feel familiar with the wiki concept. 6. As for the technical issue - mainly scalability of we want to offer a list of 150 or so pages with a real scroll (not a JS one). I'm sure (ok, I strongly hope) that here are ways to optimize the underlying storage mecanism in order for it to have an index of all spaces and an index of all pages in every space available upon request.

The problem is not necessarily the speed of retrieving the list of pages or spaces but rather the fact that showing the entire list on the client will kill the browser. Thanks, Marius

What's more, it is Laurent's job to have an insight into what our customers and users will expect. The same way I trust you guys for delivering a great architecture or clean, working and tested code, I trust Laurent for proposing an interface that actual users will want to use. I am NOT an UI engineer. Designing great UIs requires skills, experience and patience. It's all too easy for us to come and give our opinion about mockups. However if designing great interfaces was that easy our users wouldn't be saying that XWiki is hard to use :-)

So even though I would personally benefit more from the complex UI I've proposed, I think the best thing we can do for XWiki right now is to think about real people who hardly know how to use a wiki and provide them with a dead-simple, wizard-based interface with very little options that will guide them through the whole process. Let's accept it: we're not the WYSIWYG editor's target market. Our mothers are. And my mother would be definitely unable to use the interface I've suggested :-)

Guillaume

...

Thanks -Vincent

...

...

Happy coding, Anca Luca

...

...

* It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent

---

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

BTW, I thinks Anchors are given a too important place. I would keep them in the additional params Ludovic Sergiu Dumitriu wrote:

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

...

Hi,

The last proposal for links management in the wysiwyg editor can be found here : http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys...

Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me) * The screenshots are missing wiki selection (for multi wiki installs) * I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. * It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent

How about this interface:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

This works a bit like the way the Mac file explorer works. By default, when creating or editing a link, the current wiki/space/document are selected. If the user clicks on a different wiki, space or anchor, the descending columns are cleared, and a "loading" message is displayed, like in: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

For links to non-existing documents ("wanted"), under spaces and documents a custom input box can be displayed, as in: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

The list of spaces/documents is populated on display, like the RMUI tables. Above the list, a "Displaying S-E out of T" message is displayed only when the list does not fit in one page.

The anchor column can be used to link to a document section (should we display sections from the saved document, or from the edited document if the selected document is the currently edited one?), to an attachment, or to a comment. Custom ID means entering in an input box a custom ID, without any checks if such an element exists or not. Should we also have a "page section" which allows to choose between the content area, comments, attachments, history?

Each column can be filtered by entering some text in the respective box: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

Besides the "Simple" view, there's also the advanced view, and the "additional params" view.

The params view allows customizing the link, by entering target, rel, class and id attributes: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

For the advanced view I don't have screenshots, but it could contain the suggest input boxes for wiki, space and document name, and some way of selecting a custom action (view, edit, cancel, ssx...), a custom version from the history, a query string.

Sorry for the raw aspect of the drawings.

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

Hi Sergiu, First of all, thanks for the proposal. I know how busy you are. See my notes below. Sergiu Dumitriu wrote:

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

...

Hi,

The last proposal for links management in the wysiwyg editor can be found here : http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys... Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me) * The screenshots are missing wiki selection (for multi wiki installs) * I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. * It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent

How about this interface:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

This works a bit like the way the Mac file explorer works. By default, when creating or editing a link, the current wiki/space/document are selected. If the user clicks on a different wiki, space or anchor, the descending columns are cleared, and a "loading" message is displayed, like in: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

In Guillaume's proposal the user is able to insert a link to a space directly without selecting the WebHome page (same for a wiki, without selecting the Main space and the WebHome page). How is this achievable in your design? I guess there could be a button at the bottom of each list or maybe the user could double click on a list item.

For links to non-existing documents ("wanted"), under spaces and documents a custom input box can be displayed, as in: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

The list of spaces/documents is populated on display, like the RMUI tables. Above the list, a "Displaying S-E out of T" message is displayed only when the list does not fit in one page.

But the list of pages doesn't seem to be 'paginated'. I'm afraid of what could happen if there are a lot of pages (like hundreds). I guess we should look for a smart list that loads only the visible items.

The anchor column can be used to link to a document section (should we display sections from the saved document, or from the edited document if the selected document is the currently edited one?), to an attachment, or to a comment. Custom ID means entering in an input box a custom ID, without any checks if such an element exists or not. Should we also have a "page section" which allows to choose between the content area, comments, attachments, history?

Each column can be filtered by entering some text in the respective box: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

Besides the "Simple" view, there's also the advanced view, and the "additional params" view.

The params view allows customizing the link, by entering target, rel, class and id attributes: http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

For the advanced view I don't have screenshots, but it could contain the suggest input boxes for wiki, space and document name, and some way of selecting a custom action (view, edit, cancel, ssx...), a custom version from the history, a query string.

Sorry for the raw aspect of the drawings.

I'm also worried about the horizontal layout. In some cases (I suspect Watch) space and page names could be really long. I've noticed you cut the long names and added "..." to avoid horizontal scroll. Even with a tool tip showing the full name this might still be annoying for some users. Marius

Hi, I think that the various propositions we've had (from Laurent, Sergiu and I) are not that much different and that we can come to a first version that keeps most of their advantages under the tight time constraints we're working under. Here goes : 1. Provide lists only for wikis (in multiwiki mode), spaces and pages as of now (and take care about additional things that can be related to a page - headers, objects, attachments - at a later stage) 2. Going opposite to my initial thoughts, it is probably better to keep link creation towards existing and not yet existing pages in the same place. 3. On the whole we all agree on providing 3 lists: one for wikis, one for spaces, one for pages. The issue was of presenting it in 1 column with 3 steps or 3 columns. I think that given today's screen sizes, using 3 columns should work and it's not that counterintuitive to users. 4. We can follow Sergiu's proposal quite closely for each list : 1. Column title (Wikis, Spaces, Pages) 2. Dynamic filtering field 3. List of items (10 visible by default) centered on the current wiki, space, page highlighted (as in Sergiu's proposal) 4. "Or input the name of a new [space, page]" input field 5. A small italics link titled "more options" that opens a 2nd dialog box with additional options (parameters, target, anchors, etc) 6. A big, green "Create" button. Upon clicking the button, the user is brought back to the editor. | Column Title (Wikis, Spaces, Pages) | | [filter items input field] | | Item 1 | | ... | | Item 10 | | [Or input the name of a new element field] | | Advanced options | | CREATE ITEM BUTTON | WDYT ? Guillaume On Thu, Oct 30, 2008 at 12:01 AM, Sergiu Dumitriu <[email protected]> wrote:

Marius Dumitru Florea wrote:

...

Hi Sergiu,

First of all, thanks for the proposal. I know how busy you are. See my notes below.

Sergiu Dumitriu wrote:

...

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

...

Hi,

The last proposal for links management in the wysiwyg editor can be found here :

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys... Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me) * The screenshots are missing wiki selection (for multi wiki installs) * I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. * It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent How about this interface:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

This works a bit like the way the Mac file explorer works. By default, when creating or editing a link, the current wiki/space/document are selected. If the user clicks on a different wiki, space or anchor, the descending columns are cleared, and a "loading" message is displayed, like in:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

In Guillaume's proposal the user is able to insert a link to a space directly without selecting the WebHome page (same for a wiki, without selecting the Main space and the WebHome page). How is this achievable in your design? I guess there could be a button at the bottom of each list or maybe the user could double click on a list item.

If the user selects just the wiki, without selecting a space, or just the space, without selecting a doc, or the doc without selecting an anchor, then the default is used: Main.WebHome, Space.WebHome, no particular anchor. (Note that 'Main' and 'WebHome' can be customized, so be sure to use the proper API instead of hardcoded strings)

And yes, at the bottom are buttons, I didn't add them to save time, and because I thought they are obvious.

...

...

For links to non-existing documents ("wanted"), under spaces and documents a custom input box can be displayed, as in:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

The list of spaces/documents is populated on display, like the RMUI tables. Above the list, a "Displaying S-E out of T" message is displayed only when the list does not fit in one page.

But the list of pages doesn't seem to be 'paginated'. I'm afraid of what could happen if there are a lot of pages (like hundreds). I guess we should look for a smart list that loads only the visible items.

WDYM? "Like the RMUI tables" means exactly this: just the documents corresponding to the selected range are queried from the database and sent via AJAX. It is not classic paginating, but a dynamic range.

...

...

The anchor column can be used to link to a document section (should we display sections from the saved document, or from the edited document if the selected document is the currently edited one?), to an attachment, or to a comment. Custom ID means entering in an input box a custom ID, without any checks if such an element exists or not. Should we also have a "page section" which allows to choose between the content area, comments, attachments, history?

OK to move this to the params tab.

...

...

Each column can be filtered by entering some text in the respective box:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

Besides the "Simple" view, there's also the advanced view, and the "additional params" view.

The params view allows customizing the link, by entering target, rel, class and id attributes:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

For the advanced view I don't have screenshots, but it could contain the suggest input boxes for wiki, space and document name, and some way of selecting a custom action (view, edit, cancel, ssx...), a custom version from the history, a query string.

Sorry for the raw aspect of the drawings.

I'm also worried about the horizontal layout. In some cases (I suspect Watch) space and page names could be really long. I've noticed you cut the long names and added "..." to avoid horizontal scroll. Even with a tool tip showing the full name this might still be annoying for some users.

Yes, the ... mean that the document name was cropped, and the full title is displayed as a tooltip.

With a small font and the large resolutions that are frequent nowadays, I don't think this is a problem. We'll probably have to use a different for smaller devices. Something like what macs do seems good enough: Display the columns that fit, up to the most specific one selected, and the rest are hidden on the left or right sides (Ask Jerome to show you on his mac, if he still has it).

Basically, things go like this:

| Wiki | Space | | | | | wiki1 | Space1 | | wiki2 | Space2 | | |wiki3| | Space3 | > | wiki4 | Space4 | | | Space5 |

After selecting the space:

| Space | Doc | | | | | Space1 | Doc1 | | Space2 | Doc2 | < ||Space3| | Doc3 | > | Space4 | Doc4 | | Space5 | |

This allows having just 2 columns (or even 1) with plenty of space to display 80 or more small characters.

-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

Hi, I've added 2 new images showing what I had in mind: 1. http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/WYS... 2. http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/WYS... WDYT? On Thu, Oct 30, 2008 at 12:07 PM, Sergiu Dumitriu <[email protected]> wrote:

There are two things missing:

1. The link text.

The link text is the text that was highlighted in the editor prior to clicking on the "insert link" button. Right now you cannot insert a link if you have not highlighted some text beforehand.

2. A Cancel button.

There's a big red "cancel / close" button at the top right of the images I've just provided - would that be enough? Guillaume

Guillaume Lerouge wrote:

...

Hi, I think that the various propositions we've had (from Laurent, Sergiu and I) are not that much different and that we can come to a first version that keeps most of their advantages under the tight time constraints we're working under. Here goes :

1. Provide lists only for wikis (in multiwiki mode), spaces and pages as of now (and take care about additional things that can be related to a page - headers, objects, attachments - at a later stage) 2. Going opposite to my initial thoughts, it is probably better to keep link creation towards existing and not yet existing pages in the same place. 3. On the whole we all agree on providing 3 lists: one for wikis, one for spaces, one for pages. The issue was of presenting it in 1 column with 3 steps or 3 columns. I think that given today's screen sizes, using 3 columns should work and it's not that counterintuitive to users. 4. We can follow Sergiu's proposal quite closely for each list : 1. Column title (Wikis, Spaces, Pages) 2. Dynamic filtering field 3. List of items (10 visible by default) centered on the current wiki, space, page highlighted (as in Sergiu's proposal) 4. "Or input the name of a new [space, page]" input field 5. A small italics link titled "more options" that opens a 2nd dialog box with additional options (parameters, target, anchors, etc) 6. A big, green "Create" button. Upon clicking the button, the user is brought back to the editor.

| Column Title (Wikis, Spaces, Pages) | | [filter items input field] | | Item 1 | | ... | | Item 10 | | [Or input the name of a new element field] | | Advanced options | | CREATE ITEM BUTTON |

WDYT ?

Guillaume

On Thu, Oct 30, 2008 at 12:01 AM, Sergiu Dumitriu <[email protected]> wrote:

...

Marius Dumitru Florea wrote:

...

Hi Sergiu,

First of all, thanks for the proposal. I know how busy you are. See my notes below.

Sergiu Dumitriu wrote:

...

Vincent Massol wrote:

...

On Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote:

> Hi, > > The last proposal for links management in the wysiwyg editor can be > found here : >

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/wys...

...

...

...

...

Sounds nice. Some comments:

* The link menu items should be improved IMO: - I would put adding an external link at the bottom since it's not the most used one - The labels should be improved. I don't know if "wanted page" is obvious (it wasn't for me) * The screenshots are missing wiki selection (for multi wiki installs) * I'm not sure I like the wizard like approach, i.e. having to select some value before selecting others. I think I would have preferred a single screen but that's me only. * It's missing the ability to specify any number of parameters (for advanced usages)

Thanks -Vincent How about this interface:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

...

...

This works a bit like the way the Mac file explorer works. By default, when creating or editing a link, the current wiki/space/document are selected. If the user clicks on a different wiki, space or anchor, the descending columns are cleared, and a "loading" message is displayed, like in:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

...

In Guillaume's proposal the user is able to insert a link to a space directly without selecting the WebHome page (same for a wiki, without selecting the Main space and the WebHome page). How is this achievable in your design? I guess there could be a button at the bottom of each list or maybe the user could double click on a list item. If the user selects just the wiki, without selecting a space, or just the space, without selecting a doc, or the doc without selecting an anchor, then the default is used: Main.WebHome, Space.WebHome, no particular anchor. (Note that 'Main' and 'WebHome' can be customized, so be sure to use the proper API instead of hardcoded strings)

And yes, at the bottom are buttons, I didn't add them to save time, and because I thought they are obvious.

...

...

For links to non-existing documents ("wanted"), under spaces and documents a custom input box can be displayed, as in:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

...

...

The list of spaces/documents is populated on display, like the RMUI tables. Above the list, a "Displaying S-E out of T" message is displayed only when the list does not fit in one page. But the list of pages doesn't seem to be 'paginated'. I'm afraid of what could happen if there are a lot of pages (like hundreds). I guess we should look for a smart list that loads only the visible items. WDYM? "Like the RMUI tables" means exactly this: just the documents corresponding to the selected range are queried from the database and sent via AJAX. It is not classic paginating, but a dynamic range.

...

...

The anchor column can be used to link to a document section (should we display sections from the saved document, or from the edited document if the selected document is the currently edited one?), to an attachment, or to a comment. Custom ID means entering in an input box a custom ID, without any checks if such an element exists or not. Should we also have a "page section" which allows to choose between the content area, comments, attachments, history? OK to move this to the params tab.

...

...

Each column can be filtered by entering some text in the respective box:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

...

...

Besides the "Simple" view, there's also the advanced view, and the "additional params" view.

The params view allows customizing the link, by entering target, rel, class and id attributes:

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/ui....

...

...

...

For the advanced view I don't have screenshots, but it could contain the suggest input boxes for wiki, space and document name, and some way of selecting a custom action (view, edit, cancel, ssx...), a custom version from the history, a query string.

Sorry for the raw aspect of the drawings. I'm also worried about the horizontal layout. In some cases (I suspect Watch) space and page names could be really long. I've noticed you cut the long names and added "..." to avoid horizontal scroll. Even with a tool tip showing the full name this might still be annoying for some users. Yes, the ... mean that the document name was cropped, and the full title is displayed as a tooltip.

With a small font and the large resolutions that are frequent nowadays, I don't think this is a problem. We'll probably have to use a different for smaller devices. Something like what macs do seems good enough: Display the columns that fit, up to the most specific one selected, and the rest are hidden on the left or right sides (Ask Jerome to show you on his mac, if he still has it).

Basically, things go like this:

| Wiki | Space | | | | | wiki1 | Space1 | | wiki2 | Space2 | | |wiki3| | Space3 | > | wiki4 | Space4 | | | Space5 |

After selecting the space:

| Space | Doc | | | | | Space1 | Doc1 | | Space2 | Doc2 | < ||Space3| | Doc3 | > | Space4 | Doc4 | | Space5 | |

This allows having just 2 columns (or even 1) with plenty of space to display 80 or more small characters.

-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

Guillaume Lerouge wrote:

Hi,

I've added 2 new images showing what I had in mind:

1. http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/WYS... 2. http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/WYS...

WDYT?

I'm not sure that 3 Advanced options and 3 Create buttons are needed.

On Thu, Oct 30, 2008 at 12:07 PM, Sergiu Dumitriu <[email protected]> wrote:

...

There are two things missing:

1. The link text.

The link text is the text that was highlighted in the editor prior to clicking on the "insert link" button. Right now you cannot insert a link if you have not highlighted some text beforehand.

OK... Is that intuitive? What do users expect?

...

2. A Cancel button.

There's a big red "cancel / close" button at the top right of the images I've just provided - would that be enough?

If this is consistent with all the other dialogs, yes. By the way, that big X could be the XWiki X. -- Sergiu Dumitriu http://purl.org/net/sergiu/

On Thu, Oct 30, 2008 at 12:43 PM, Sergiu Dumitriu <[email protected]> wrote:

Guillaume Lerouge wrote:

...

Hi,

I've added 2 new images showing what I had in mind:

1.

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/WYS...

...

2.

http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/WYS...

...

WDYT?

I'm not sure that 3 Advanced options and 3 Create buttons are needed.

I think you need 3 buttons because you could have a space and a page highlighted at the same time: in this case, how can the user create a link towards the space homepage for instance? He needs to have a way to select which one he wants to link to.

...

On Thu, Oct 30, 2008 at 12:07 PM, Sergiu Dumitriu <[email protected]> wrote:

...

There are two things missing:

1. The link text.

The link text is the text that was highlighted in the editor prior to clicking on the "insert link" button. Right now you cannot insert a link if you have not highlighted some text beforehand.

OK... Is that intuitive? What do users expect?

Here's a proposal on the topic: since the link label can be edited in the editor, upon link insertion when the target page is selected we could put "SpaceName.PageName" as a label in the editor. Then the user can still change it by inserting the cursor in the selection and replacing it with some other text.

...

...

2. A Cancel button.

There's a big red "cancel / close" button at the top right of the images I've just provided - would that be enough?

If this is consistent with all the other dialogs, yes. By the way, that big X could be the XWiki X.

-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

Hi everyone, Here's my (late) reaction to the discussion about managing links in the new wysiwyg: All the proposals target users who are XWiki beginners and need guidance in their actions. This is good, of course, for a newbie it's the right approach, but a more experienced user will be *very* annoyed with all the clicking and tabbing and browsing that is necessary in order to create a link. Experienced users should also have the right to use the wysiwyg without being slowed down by all the help it offers. Consequently, I would propose to provide two ways of creating the link. In the dedicated dialog, there should be two areas (sorry i didn't make a drawing): - top: a small zone for those who know what they are doing, with a single input endowed with a "smart" suggest feature. - under it, a bigger zone containing one of the proposed complex selection interfaces. In my opinion, this zone should be collapsed for advanced users. Here's an example that illustrates how the link input would work. When the user starts writing "de" in the input, the suggestions will include all wikis, spaces from the current wiki and pages from the current space that start with "de", for example in this form: *de*v: *De*velopment. CurrentSpace.*De*tails (For experienced users, it will be obvious that what ends with ":" is a virtual wiki, what ends with "." is a space in the current wiki, etc. Maybe some color codes can be used in the suggestion list to help them to quickly spot what they need, and, for a "richer" experience, the different fragments of the path can be displayed in the input with that color, for example: purple for wikis, blue for spaces, green for pages. The same color codes could be used in the beginner's zone as well.) If the user chooses "dev:", then at that point we start suggesting, according to the user's input, spaces from that wiki, and so on. Also, whenever the user hits ":" (not necessarily by choosing explicitly one of the suggestions), we realize that so far he specified a virtual wiki, and start making suggestions of spaces from that wiki. So, basically, this is addressed to users that know the syntax of an internal wiki link, know where they want to link, and just want to type it quickly. (offtopic: such an input would also be very useful for implementing Vincent's idea XWIKI-1485). Of course, the user may be wrong and try to point to a page that does not exist. He will be informed about the mistake with a small warning somewhere around the input, but he will be allowed to continue (maybe he knows what he's doing; otherwise he would have used the wizard :) ). A complex selection interface is very necessary and can under no circumstances be replaced by this toy, but, in my opinion, if the beginners are properly helped by it and shown the result of their actions, some may start to understand how to write the paths without all the guidance and end up preferring to use the more simple and quick variant. I'm thinking that maybe the two (the input and the selector) should be at all time "synchronized". I'm aware that probably there's not enough time to do everything before 1.7, but imo this approach would really boost the usability for all categories of users.

Yes +1 This is exactly what I had in mind too. And yes we should make the control reusable for navigating to any page quickly. Thanks -Vincent On Oct 30, 2008, at 2:40 PM, Marta Girdea wrote:

Hi everyone,

Here's my (late) reaction to the discussion about managing links in the new wysiwyg:

All the proposals target users who are XWiki beginners and need guidance in their actions. This is good, of course, for a newbie it's the right approach, but a more experienced user will be *very* annoyed with all the clicking and tabbing and browsing that is necessary in order to create a link. Experienced users should also have the right to use the wysiwyg without being slowed down by all the help it offers.

Consequently, I would propose to provide two ways of creating the link. In the dedicated dialog, there should be two areas (sorry i didn't make a drawing): - top: a small zone for those who know what they are doing, with a single input endowed with a "smart" suggest feature. - under it, a bigger zone containing one of the proposed complex selection interfaces. In my opinion, this zone should be collapsed for advanced users.

Here's an example that illustrates how the link input would work. When the user starts writing "de" in the input, the suggestions will include all wikis, spaces from the current wiki and pages from the current space that start with "de", for example in this form: *de*v: *De*velopment. CurrentSpace.*De*tails (For experienced users, it will be obvious that what ends with ":" is a virtual wiki, what ends with "." is a space in the current wiki, etc. Maybe some color codes can be used in the suggestion list to help them to quickly spot what they need, and, for a "richer" experience, the different fragments of the path can be displayed in the input with that color, for example: purple for wikis, blue for spaces, green for pages. The same color codes could be used in the beginner's zone as well.)

If the user chooses "dev:", then at that point we start suggesting, according to the user's input, spaces from that wiki, and so on. Also, whenever the user hits ":" (not necessarily by choosing explicitly one of the suggestions), we realize that so far he specified a virtual wiki, and start making suggestions of spaces from that wiki.

So, basically, this is addressed to users that know the syntax of an internal wiki link, know where they want to link, and just want to type it quickly.

(offtopic: such an input would also be very useful for implementing Vincent's idea XWIKI-1485).

Of course, the user may be wrong and try to point to a page that does not exist. He will be informed about the mistake with a small warning somewhere around the input, but he will be allowed to continue (maybe he knows what he's doing; otherwise he would have used the wizard :) ).

A complex selection interface is very necessary and can under no circumstances be replaced by this toy, but, in my opinion, if the beginners are properly helped by it and shown the result of their actions, some may start to understand how to write the paths without all the guidance and end up preferring to use the more simple and quick variant. I'm thinking that maybe the two (the input and the selector) should be at all time "synchronized". I'm aware that probably there's not enough time to do everything before 1.7, but imo this approach would really boost the usability for all categories of users. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Oct 31, 2008, at 11:50 AM, Guillaume Lerouge wrote:

Hi,

I personally like Marta's suggestion a lot (that's definitely be the one I would use) and I think providing it to users would be cool. However displaying both input methods on the same page might look clunky.

What we could do is to take advantage of XWiki's simple user / advanced user feature: we could display the full graphical interface for simple user and the quick input one for advanced users, or maybe have 2 tabs with the simple one selected for simple users and the advanced one selected for advanced users when they click on the "add link" button.

WDYT?

No sure. I thought about this too a few days ago but I thought it would be too "magical" and as an advanced user I might want to use the navigation part too. I don't know so I would say +0. Thanks -Vincent

On Thu, Oct 30, 2008 at 3:30 PM, Vincent Massol <[email protected]> wrote:

...

Yes +1

This is exactly what I had in mind too.

And yes we should make the control reusable for navigating to any page quickly.

Thanks -Vincent

On Oct 30, 2008, at 2:40 PM, Marta Girdea wrote:

...

Hi everyone,

Here's my (late) reaction to the discussion about managing links in the new wysiwyg:

All the proposals target users who are XWiki beginners and need guidance in their actions. This is good, of course, for a newbie it's the right approach, but a more experienced user will be *very* annoyed with all the clicking and tabbing and browsing that is necessary in order to create a link. Experienced users should also have the right to use the wysiwyg without being slowed down by all the help it offers.

Consequently, I would propose to provide two ways of creating the link. In the dedicated dialog, there should be two areas (sorry i didn't make a drawing): - top: a small zone for those who know what they are doing, with a single input endowed with a "smart" suggest feature. - under it, a bigger zone containing one of the proposed complex selection interfaces. In my opinion, this zone should be collapsed for advanced users.

Here's an example that illustrates how the link input would work. When the user starts writing "de" in the input, the suggestions will include all wikis, spaces from the current wiki and pages from the current space that start with "de", for example in this form: *de*v: *De*velopment. CurrentSpace.*De*tails (For experienced users, it will be obvious that what ends with ":" is a virtual wiki, what ends with "." is a space in the current wiki, etc. Maybe some color codes can be used in the suggestion list to help them to quickly spot what they need, and, for a "richer" experience, the different fragments of the path can be displayed in the input with that color, for example: purple for wikis, blue for spaces, green for pages. The same color codes could be used in the beginner's zone as well.)

If the user chooses "dev:", then at that point we start suggesting, according to the user's input, spaces from that wiki, and so on. Also, whenever the user hits ":" (not necessarily by choosing explicitly one of the suggestions), we realize that so far he specified a virtual wiki, and start making suggestions of spaces from that wiki.

So, basically, this is addressed to users that know the syntax of an internal wiki link, know where they want to link, and just want to type it quickly.

(offtopic: such an input would also be very useful for implementing Vincent's idea XWIKI-1485).

Of course, the user may be wrong and try to point to a page that does not exist. He will be informed about the mistake with a small warning somewhere around the input, but he will be allowed to continue (maybe he knows what he's doing; otherwise he would have used the wizard :) ).

A complex selection interface is very necessary and can under no circumstances be replaced by this toy, but, in my opinion, if the beginners are properly helped by it and shown the result of their actions, some may start to understand how to write the paths without all the guidance and end up preferring to use the more simple and quick variant. I'm thinking that maybe the two (the input and the selector) should be at all time "synchronized". I'm aware that probably there's not enough time to do everything before 1.7, but imo this approach would really boost the usability for all categories of users. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Guillaume Lerouge wrote:

Hi,

I personally like Marta's suggestion a lot (that's definitely be the one I would use) and I think providing it to users would be cool. However displaying both input methods on the same page might look clunky.

What we could do is to take advantage of XWiki's simple user / advanced user feature: we could display the full graphical interface for simple user and the quick input one for advanced users, or maybe have 2 tabs with the simple one selected for simple users and the advanced one selected for advanced users when they click on the "add link" button.

WDYT?

But this means that users will not be able to learn the syntax and switch to advanced users. And Simple/Advanced is more than how well do they know how the wiki works. There could be users that want to enter links fast, but don't want to know about object editing. I think that keeping both is OK, provided the two areas are delimited, and the "wizard" can be collapsed. The smart input is small and doesn't take too much space. It's important to make it clear that the two are alternatives, and they don't have to use both in order to enter a link.

Guillaume

On Thu, Oct 30, 2008 at 3:30 PM, Vincent Massol <[email protected]> wrote:

...

Yes +1

This is exactly what I had in mind too.

And yes we should make the control reusable for navigating to any page quickly.

Thanks -Vincent

On Oct 30, 2008, at 2:40 PM, Marta Girdea wrote:

...

Hi everyone,

Here's my (late) reaction to the discussion about managing links in the new wysiwyg:

All the proposals target users who are XWiki beginners and need guidance in their actions. This is good, of course, for a newbie it's the right approach, but a more experienced user will be *very* annoyed with all the clicking and tabbing and browsing that is necessary in order to create a link. Experienced users should also have the right to use the wysiwyg without being slowed down by all the help it offers.

Consequently, I would propose to provide two ways of creating the link. In the dedicated dialog, there should be two areas (sorry i didn't make a drawing): - top: a small zone for those who know what they are doing, with a single input endowed with a "smart" suggest feature. - under it, a bigger zone containing one of the proposed complex selection interfaces. In my opinion, this zone should be collapsed for advanced users.

Here's an example that illustrates how the link input would work. When the user starts writing "de" in the input, the suggestions will include all wikis, spaces from the current wiki and pages from the current space that start with "de", for example in this form: *de*v: *De*velopment. CurrentSpace.*De*tails (For experienced users, it will be obvious that what ends with ":" is a virtual wiki, what ends with "." is a space in the current wiki, etc. Maybe some color codes can be used in the suggestion list to help them to quickly spot what they need, and, for a "richer" experience, the different fragments of the path can be displayed in the input with that color, for example: purple for wikis, blue for spaces, green for pages. The same color codes could be used in the beginner's zone as well.)

If the user chooses "dev:", then at that point we start suggesting, according to the user's input, spaces from that wiki, and so on. Also, whenever the user hits ":" (not necessarily by choosing explicitly one of the suggestions), we realize that so far he specified a virtual wiki, and start making suggestions of spaces from that wiki.

So, basically, this is addressed to users that know the syntax of an internal wiki link, know where they want to link, and just want to type it quickly.

(offtopic: such an input would also be very useful for implementing Vincent's idea XWIKI-1485).

Of course, the user may be wrong and try to point to a page that does not exist. He will be informed about the mistake with a small warning somewhere around the input, but he will be allowed to continue (maybe he knows what he's doing; otherwise he would have used the wizard :) ).

A complex selection interface is very necessary and can under no circumstances be replaced by this toy, but, in my opinion, if the beginners are properly helped by it and shown the result of their actions, some may start to understand how to write the paths without all the guidance and end up preferring to use the more simple and quick variant. I'm thinking that maybe the two (the input and the selector) should be at all time "synchronized". I'm aware that probably there's not enough time to do everything before 1.7, but imo this approach would really boost the usability for all categories of users.

-- Sergiu Dumitriu http://purl.org/net/sergiu/