Vincent Massol wrote: > On Nov 28, 2008, at 2:59 PM, Laurent Lunati wrote: > >> Le 28 nov. 08 à 14:12, Vincent Massol a écrit : >> >>> On Nov 28, 2008, at 1:59 PM, Laurent Lunati wrote: >>> >>>> Le 28 nov. 08 à 12:35, Jean-Vincent Drean a écrit : >>>> >>>>> On Fri, Nov 28, 2008 at 12:11 PM, Vincent Massol >>>>> <[EMAIL PROTECTED]> wrote: >>>>>>> 2 steps do not seem excessive to me, it's still gonnna be real >>>>>>> quick >>>>>>> and it >>>>>>> adapts well to the various use cases we are faced with (insert >>>>>>> link, >>>>>>> insert >>>>>>> image etc). It has both the benefits from the wizard and the >>>>>>> treeview. I >>>>>>> think it is a great middle ground between our various proposals. >>>>>> 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. >>>>>> >>>>> See >>>>> http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer#HMockup-4 >>>>> >>>>> I'm fine with this solution, Laurent WDYT of this one ? >>>>> >>>>> JV. >>>> it's not the right way for me, with a direct insert button common >>>> usage is : >>> 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).
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. >>> 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. >> >> I really don't know what to anser.... so starting here i stop to >> discuss. > > 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. 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. > Hope you'll reconsider and continue discussing here. > > Thanks > -Vincent > >>>> 1 - select >>>> 2 - insert >>>> 3 - Ho zut >>>> 4 - edit ? >>>> 5 - ho... am i on the right box ? >>>> 6- click on edit (or close the dialogue, in this case delete img and >>>> reclick on insert image) >>>> 7 - reselect img >>>> 8 - ok more options... >>>> 9 - ha... yes my image is too big >>>> 10 - change option >>>> 11 - insert >>>> >>>> if you have 2 steps on inserting dialogue always display all step, >>>> so >>>> that user always know where he is >>>> >>>> laurent 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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
