Sergiu Dumitriu wrote: 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. 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:

Vincent Massol wrote: Done. ok, I'll see what I can do during the weekend.

Hi guys, [lots of snapping below] *Marius* 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* *Vincent* *Marius* 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: 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

Vincent Massol wrote: +1 -- Sergiu Dumitriu http://purl.org/net/sergiu/

Hi Paul, Paul Libbrecht wrote: No. I was considering using it for its Selection support, but I discovered this support is limited for what I need. Thanks for the tip. 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 Oct 28, 2008, at 3:56 PM, Jean-Vincent Drean wrote: 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: Yes 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

Anca Paula Luca wrote: 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.

Hi, On Tue, Oct 28, 2008 at 5:30 PM, Vincent Massol <vincent(a)massol.net> wrote: 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. 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 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 -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

Hi Guillaume, Guillaume Lerouge wrote: 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). I don't think user dissatisfaction resets after each day but grows till a the user finds a better solution elsewhere. 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

BTW, I thinks Anchors are given a too important place. I would keep them in the additional params Ludovic Sergiu Dumitriu wrote: -- 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: 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. 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. 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 <sergiu(a)xwiki.com> wrote: -- 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/WY… 2. http://dev.xwiki.org/xwiki/bin/download/Design/NewWysiwygEditorInterface/WY… WDYT? On Thu, Oct 30, 2008 at 12:07 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: 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. 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 Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

Guillaume Lerouge wrote: I'm not sure that 3 Advanced options and 3 Create buttons are needed. OK... Is that intuitive? What do users expect? 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 <sergiu(a)xwiki.com> wrote: 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. 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. -- 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:

On Oct 31, 2008, at 11:50 AM, Guillaume Lerouge wrote: 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

Guillaume Lerouge wrote: 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. -- Sergiu Dumitriu http://purl.org/net/sergiu/