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/wysiwyg%2Dsuite.pdf > >>>> 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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
