On Tue, Nov 25, 2008 at 5:16 PM, Vincent Massol <vincent(a)massol.net> wrote: There's filter option at the bottom-right of the (pretty big) mockup :) JV.

Hi, On Tue, Nov 25, 2008 at 5:26 PM, Vincent Massol <vincent(a)massol.net> wrote: I'm non-binding +1 for 3) B with the filter. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

On Nov 25, 2008, at 5:35 PM, Thomas Eveilleau wrote: You should try doing this in the XWiki space on xwiki.org... then come back here :) There are 2 problems: 1) it won't work when there are a large number of documents (for ex, there are thousands of XWiki users on xwiki.org) 2) it's not intuitive at all since the user has to scroll to see the action. How will he know he has to do that to add a new page if that link is not visible? Thanks -Vincent

On Tue, Nov 25, 2008 at 5:45 PM, Anca Paula Luca <ancapaula.luca(a)xwiki.com> wrote: Thanks for summarizing my thoughts on this :) JV.

Vincent Massol wrote: I assumed that if you know _for sure_ that you want to add a page, then you know what you're doing, and adding your "path" in the input box on the right (wiki:space.newpage) would be the easier choice for you anyway. I admit my assumption might not hold, but I find it probable enough.

Vincent Massol wrote: A very good qustion which brings the subject of references to unexisting objects from the "advanced users input". We could do some tricks (since we're providing file preview anyway) to have an upload box load in the place of the preview when the file does not exist, but I don't think I like this very much from an implementation standpoint (and a pretty crowded UI -- speaking of which, is this whole thing supposed to be displayed in a dialog / lightbox ?). C) could do the job still, but I don't like the idea of having "create new" options in the exploration tool _above_ all options, I think it eludes the concept of an exploration tool by encouraging the users to add new before search existing.

On Nov 27, 2008, at 7:49 PM, Vincent Massol wrote: ok I think I understand now. I was expecting a mockup for link insertion. I understand this too now. I was misled by the fact that in the second row the node was selected where actually the user is supposed to click on "upload file" (which should be highlighted) Thanks -Vincent

On Thu, Nov 27, 2008 at 8:02 PM, Vincent Massol <vincent(a)massol.net> wrote: The only solution I see for this is to have a tooltip with a preview in the treeview. Yes. This mockup is about the wiki explorer, I've put the example of the image insertion but this part is not to be taken as a proposal. s/user/power user/ IMHO an extra click is only a problem if the user has to think where to click and why to click. I agree that 2 or more extra clicks are a problem but only one, with the action button always at the very same place, no. I don't think so, actually that's why I came up with 4). JV.

I vote +1 for 4, and i don't consider 3 as a valid proposal Laurent Le 28 nov. 08 à 08:31, Marius Dumitru Florea a écrit :

Le 28 nov. 08 à 09:58, Vincent Massol a écrit : yes, but it would take too much time to me to build an clear and argued answer. and I do not have this time. I thing i must find the right way for giving you all informations without having to rewrite them on each mail. i have to work on that... laurent

Jean-Vincent Drean wrote: I was thinking about navigating the tree using the keyboard. This is a nice thing to have. It can be done in both proposal 3 and 4.

On Nov 27, 2008, at 9:14 PM, Jean-Vincent Drean wrote: Couldn't we show the images in the tree (as thumbnails)? In several wikis/CMS I've seen they use a media browser showing thumbnails of pictures and this looks a good way to select the picture to me. If I have to open all nodes to see the pictures below it might be hard to select the picture I want. It might be better to list all pictures found in a given space or wiki (still using a live grid so that performances are not penalized of course). Maybe a checkbox to switch from treeview to image browser? Why do you say that? With your argument every user is dumb and would not be able to use a computer at all. Have you every seen a computer OS screen when there's only 1 button and wizards to go to the next step? Come on, look at your screen, and see all the buttons and places you can click (right now when typing this I can see at least 100 locations I can click and I'm on a Mac, reputed for being easy to use). Life is not just a wizard! :) I agree we should not make complex screen but there's a fine line between complex and useful. I even don't disagree with option 4 even though I don't think it's required (unless we wanted to make it work on mobile devices for ex but then it's a completely different skin that we would need and it would be pretty stupid to use a mobile device design on large screens since you'd loose lots of screen estate). Ok back to constructive comments: What about 2 buttons on the first screen: * Insert * More Options... If you click insert you're done and the image is inserted right away. If you click options... then we have 2 possibilities: 1) it opens a drawer or 2) you go to the second screen. In the drawer/second screen you would specify additional stuff like image size, advanced style parameters, etc. It's not as good as option 3 but it's close since you can skip one step by clicking "Insert" right away. Also "our super dumb users" would not see the options immediately so they would not run away :) WDYT? I agree it's not a big deal. Still I'm unsure why we need 2 screens. The one argument that seems valid to me is screen estate but then I'm not sure it wouldn't fit (we need to have it work on 1024x768 and not lower since all our site is made to work on 1024x768). [snip] Thanks -Vincent

On Nov 28, 2008, at 11:50 AM, Guillaume Lerouge wrote: You didn't comment on my proposal to be able to click insert on the first screen if you don't need any option applied to the image. I think it's reasonable and saves unnecessary clicks. Re the guided stuff just one comment: users just need to be guided on their first usage of it. Thereafter all they need is productivity. This would work too with option 3. The action button would always be at the same position. The second/right screen is not about action buttons, it's about choosing options. Yes, no doubt about this. That's why action buttons are always placed at the bottom of dialog screens. However having fixed size dialog boxes is another matter and I don't believe in it. We should do it when we can but it really depends on the content we need to display. Forcing a second screen in a wizard fashion is not always good. It's only good *IF* the second screen is mandatory, if it's not then a drawer or tabs is a better solution. In our case at hand the second screen is optional and this is why a wizard is not a good structure. Thanks -Vincent

On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol <vincent(a)massol.net> wrote: See http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMo… I'm fine with this solution, Laurent WDYT of this one ? JV.

On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote: Exactly my point! This is exactly why I've always thought it was better to show the second screen so that the user can see what the options are before clicking on insert (that's proposal 3). The more I think of this and the more I think it's wrong to use a wizard to *force* a second optional step for inserting an image (especially when in the second screen won't be used at all in most cases). Resizing an image is not an option that people will systematically choose (quite the opposite) and moreover a much better way to resize an image is to use the mouse and resize the image directly in the text as it's done currently with tinyMCE (only problem being with very large images spanning more than the viewport). I'd hate to loose that feature. The scenario by Laurent below simply shows that using a dialog box to resize an image is wrong. In order to know the correct size you need to see it in the page with the rest of the layout so it's way better to offer mouse handles to resize it inline IMO. Thanks -Vincent

Jean-Vincent Drean wrote: Same in IE. You can even drag and drop the image within the edited document.

On Nov 28, 2008, at 2:59 PM, Laurent Lunati wrote: I'm surprised by your reaction Laurent. JV is proposing to have a 2 step wizard for inserting an image. I comment that the second step is not necessary IMO since it only contains optional features that are not going to be used in the majority of cases (especially if we agree that resizing should be done inline and not in the dialog box - You didn't even answer that part, does it mean you think resizing should not be done inline?) and you end up the conversation saying that you don't know what to answer... I think you're missing the fact that a good discussion is always healthy. You might think that you're always right and that there's no point in discussing with others but that's simply not true. Look at your initial proposal with 5 wizard screens. This is what we would have now if we had blindly accepted your proposal. I'm glad we didn't since this has lead to thinking more about it and JV proposed the treeview solution which has had unanimous approval and is better according to everyone. OTOH maybe you're fed up discussing because you've already discussed all this with JV before. Fair enough but then none of us was involved and we can't know what was discussed. In addition I don't think we're far from having found our best solution. Once more my only remaining concern is to systematically force users to go through a second screen that they would not use. While this is ok the first time I think it would hamper usability after a few image insertions. Actually I have another concern which is how to use the treeview to efficiently choose an image. While choosing the image based on its name is possible I remember seeing other wikis that are doing better by showing image galleries to pick from. Hope you'll reconsider and continue discussing here. Thanks -Vincent

Vincent Massol wrote: Most wizards I've seen in Excel have Next and Done buttons. A user can go through every step, or he can "be done" at any moment, leaving the defaults for the unexplored steps. There's a difference. An image gallery works when the images are in one or few places, not when you have thousands of pages in hundreds of spaces (think Curriki), most of which are of no interest to you. TANSTAAFL. No UI is the best for all people and all use cases. We could have several ways of choosing an image: tree based, most recently used, media gallery collecting pictures from different sets of pages (current page, current space, all wiki, recently changed documents, recently uploaded images, ...). The user would choose the best for him, or the best for the given scenario. Sometimes I just want to link to a precise image, and I can go to it "with my eyes closed", sometimes I want to insert a bluey image, and sometimes I want to use an image I remember seeing a few days ago somewhere, can't remember where exactly, but somewhere in one of these 5 documents. We could use Google Gears to keep track of the last preferences, since cookies are too expensive, and serverside increases the storage needlessly. But that's for the future. This is a scenario. A possible one. But not a frequent one, and most certainly not the most common. So a few users will have to loose some seconds a few times until they learn how to do it the right way. But it will also save a little time from everybody else EVERY time. A little bit every time versus a bit more on a few occasions is an obvious choice for me. Usually IT solutions are chosen and imposed in a company. If some guy or gal gets his little brain confused by the fact that more options are behind the "more options" button, he won't matter. Brainless secretaries don't make IT decisions. They are a big part of our users, but they are not the ones that decide what product to choose. I tend to believe that we are trying to develop a powerful wiki. XWiki has many features nobody else has (yet), and it is certainly not targeted as a Word replacer (Google Docs does a good job here). If users need power, they will choose XWiki. If they just need something to write notes on, then I personally wouldn't recommend XWiki to them to begin with. Yes, a few people chose something else because of the WYSIWYG, but not because it was a tad more difficult to use, because it was REALLY BUGGY, and I agree with them. Our TinyMCE editor is almost useless for anything more complex than writing a plain letter with a few bold words, and I never use it because of this. As long as we have as little bugs as possible, and it doesn't prove to be extremely complex, I say we're safe. More, if a client really needs a simple UI that can be used by a group of mentally retarded children, we can always do some custom development. It is important to have a configurable editor, not to have ONE interface that can satisfy everybody from hard-core hackers and 3-year youngsters. By the clickety current look of the WYSIWYG editor, I am pretty sure I'll stay away from it. -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 and 4 are interesting. But I think 4 is more easy for users so my vote is: +1 for 4 and +0 for 3 Thanks for your good job. -- View this message in context: http://n2.nabble.com/-VOTE--UI--WYSIWYG-Wiki-Explorer-tp1576940p1598053.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

On Fri, Nov 28, 2008 at 12:13 PM, Jean-Vincent Drean <jv(a)xwiki.com> wrote: I agree with this. A typical user has a choice between 3 OSes and has to have one, therefore he had to learn how his favorite one worked. When it comes to wikis, there are 50+ options out there and since it's server-based it's really easy for an admin to change the wiki software used by a large population based on user feedback. If an user cannot use the tool the very first time he uses it, there will be not second time, thus the productivity argument really is conditional on the user being able to complete the action he wants to in the first place. The level 1 objective is action completion, productivity is a level 2 objective compared to it. Therefore, the easier it is to use the better it is. Re the productivity argument, it can be addressed using the additional "insert" / "more options" buttons Vincent suggested. Plus power users will keep using the wiki syntax => another option we might want to explore in the future being syntax autocompletion in the wiki editor, close to what IDEs (and XEclipse's latest release if I understand right) already do ;-) -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

On Dec 1, 2008, at 10:48 AM, Jean-Vincent Drean wrote: I'm ok with 4 as well. My only comment is that maybe it would be best to have 2 buttons in the action list: one for the action (e.g. "Insert") and one for the next step ("Next"). For Link and image insertion we would have the "Insert" button active and for the Macro insertion it would be greyed out since we want to force the user to go to the second screen (since he needs to fill the macro parameters (for the mandatory ones) + the macro content. Thanks -Vincent