Hi Guillaume, On Oct 29, 2008, at 10:16 AM, 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/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. I'd rather just have "create link" and in the screen where you select the location you simply have the option to enter a non-existing page (which will be marked as such). For example in the filtering combos, if you type something that doesn't exist, there'll be a text in some color (say orange) that'll say something like "the link will be created to a non existing page and users will be offered to create the page when clicking on that link". >>>>>> * 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. No. We need it to be fast and simple. This is not fast and will make people move away from xwiki which is a definite FAIL. Usually what happens in most software I know is that the first time you use the software you use a wizard and thereafter the wizard disappears since wizards are a pain and not performant. > 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) Sure but some options can be hidden by default like inking to an anchor or to an attachment. Only the one that are always required should be visible. > 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? A lot. BTW this is one of the MAIN purpose of a wiki. It's the ESSENCE of a wiki (the ability to create link quickly) so I completely disagree with you. > 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. Yes that's fine with me provided it's on one screen (like the Mac Finder column view) and provided that you can also search on that screen. And provided you can jump directly to choosing a doc name rather than having to select the wiki and the space (since that happens most of the time). > 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. I don't agree. One of our goal with the new WYSIWYG is to make it easy and nice to use for everyone. It's a bad design IMO to make something slow voluntarily. > 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. That's the same as the RMUI. Only the visible pages are fetched as you type. > 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 :-) I don't agree with this at all. I'm very -1 on this. There's no single authority when developing an open source project in a collaborative manner. Everyone can make proposals but they are *only* proposals. Nobody as more power than anyone else simply because he's a said expert in the field. People will trust that person on what he proposes not on his title. Everyone has the same power to propose something. So yes I'm very happy that Laurent makes proposals and it's very likely that his proposals will please people (since he's an expert designer) but you can't say we have to accept whatever Laurent proposes *WITHOUT* any justification and *WITHOUT* questioning his choices. > 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 :-) It's a balance. Right now 99.99999% percent of our user's target are not your mother (not mine at least ;)). They are people who have used a computer before and business professionals (and slightly more on the techy side). but you can't say we'll have a tutorial to explain how to use a mouse everytime someone wants to insert a link because there are people who haven't used a mouse yet. There needs to be a limit. I really think that the WYSIWYG editor should be usable by tech people too. Last, even for novice users once they've inserted, say 2-3 links with the wizard, they'll want a faster way to do so. It must be possible for a user to simply start typing a page name right away and then (optionally) select where to put it afterwards. Thanks -Vincent >>>>>> * 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
