On Nov 29, 2008, at 6:17 AM, Sergiu Dumitriu wrote: > 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.
+1. This is also what I was suggesting when I was proposing an option to switch from the treeview to an image gallery mode. I also would like to see inside the treeview a branch labelled "Last viewed pages/ images". Thanks -Vincent > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
