> Hi, > > I've added a fourth proposal : > > http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface#HProposalNumber4 > > WDYT ?
I like it. However, the way we group the features in the menu bar is very important. I think we should find the right balance between putting every option in the menu and putting every option in the associated dialog/wizard. For instance I think it would be wrong to have an Import menu with entries for any file format you could think of, as it would be wrong to have a single Import button opening a dialog/wizard with options for any of those file formats. One solution I can think of is to have a menu entry like "Import Office Documents" which opens a dialog/wizard from where you can select what kind of Office document you want to import. In the same way, we could have a single "Link to Document" menu entry with an option on the dialog to create the document if it doesn't exist. Guillaume, you should know that in the end the layout (what features and in what order) of the tool bar, menu bar, tab bar, or whatever we'll decide on, will not be hard-coded but read from the configuration. For instance, the layout of the tool bar could be specified as: "Bold Italics Strikethrough Underlined | BulletedList NumberedList | ..." Thanks for listening, Marius > > Guillaume > > On Thu, Jun 26, 2008 at 9:24 AM, Marius Dumitru Florea < > [EMAIL PROTECTED]> wrote: > >> 1. _Only_ tool bar >> As long as it doesn't contain too many features on it, say more than 20, >> a >> tool bar is the best solution for me. It wont lead to a dialog box >> overload if they are modal and we use wizards. But anyway, the dialog >> box >> "problem" is not a consequence of the _only_ tool bar solution. In order >> to scale, a tool bar must be complemented by something else to put the >> extra, not so common, features. This _something else_ could be provided >> by >> the other two solutions proposed. >> >> 2. Menu bar & tool bar >> The extra features are organized in a menu bar, which could be detached >> through configuration thus obtaining a light editor for smaller text >> areas. I don't think the menus would require extensive cross-browser >> testing to make sure everything works fine, and I don't think things >> might >> break more easily. I believe there are way to organize the menus >> efficiently, from the usability point of view. This solution must be >> further complemented by modal dialog boxes (and wizards). >> >> 3. Tabs, each with its own tool bar >> I don't find it modern because I have the feeling I've seen it in old >> 80's >> screen shots. Rediscovering the past is not bad, as long as we value the >> usability. Speaking of which, here's some of the things I don't like: >> >> * Because we can't know a priori the size of the editor (depends on the >> client needs) we can't limit the size of the "dialog boxes" to the size >> of >> the editor. Scroll bars are out of discussion in this case. For the same >> reason, I don't think the inspector and chat panels will scale. The user >> will end up wanting to resize horizontally this panels. What will then >> happen with the tabs and the text area?.. >> * The dialog boxes will cover the text area without allowing the user to >> move them in order to see the text while filling the specific dialog >> form. >> In the menu-bar solution, even though the dialog boxes are modal, they >> can be moved (they are not "physically" bound to the menus that trigger >> them). >> * I can't see how it will degrade to a light editor for smaller text >> areas. >> * Some of our clients might not need all the features and we might end >> up >> giving them an editor with 6 tabs, each with 2 sub-features. In other >> words, a great editor should scale gracefully from 1 feature to 100 >> (organized in menu, tags or whatever). >> * I don't think having a default tab and returning "blindly" to it after >> each action is smart. What if I want to repeat my last action? >> >> Hope this will trigger some thoughts, >> Marius >> >> > Hi fellow XWikiers, >> > I've been spending some time thinking about the new User Interface we >> > might >> > want to build for the new WYSIWYG editor. I've posted the ideas I >> gathered >> > so far on this page : >> > http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterface . >> > >> > I'd be glad to get some feedback either on the list or in comments >> right >> > on >> > the page in order to see whether any given approach clinches or >> clashes >> > with >> > your own conceptions of a great rich text editor. >> > >> > Please bear in mind that I'll probably be adding content to the page >> on a >> > regular basis in days to come in order to account for the feedback >> > received >> > - if any. >> > >> > In case of an absence of feedback, well, I guess we'll be able to >> assume >> > safely that the new WYSIWYG editor doesn't matter that much in the end >> and >> > stop its development altogether ;-) >> > >> > Looking forward hearing from you guys (and girls), >> > >> > Guillaume >> > _______________________________________________ >> > devs mailing list >> > devs@xwiki.org >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> >> >> _______________________________________________ >> devs mailing list >> devs@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > http://wikibc.blogspot.com/ > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
