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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs